`crq serve` had to be started by hand and died with the terminal that started
it, which is a poor property for the thing you look at to find out whether the
fleet is healthy.

`crq serve install` writes a systemd user unit, or a launchd agent on macOS,
and starts it — the same shape as `crq autofix install`, deliberately much
thinner. That one bakes the whole fleet configuration into the unit because a
fix session's behaviour has to be pinned at install time. The dashboard reads
the same config file every other command reads, so its unit carries a path and
nothing else: editing ~/.config/crq/env then changes the dashboard by
restarting it rather than by reinstalling it.

--dry-run prints the plan and writes nothing, so the unit can be read before it
exists. A start that fails leaves the unit file in place and says which command
to run by hand, rather than reporting a dashboard that is not up.

The settings that govern a whole fleet lived in ~/.config/crq/env on whichever
machine happened to run the daemon. Changing one meant editing a file per host
and hoping they agreed — and the dashboard could only display them.

They now have a record in shared state, and reading one is three layers, least
specific first: this host's env, then the fleet record, then a repository's own
override. Every field is optional and absent means "keep using env", so a fleet
that never writes a record behaves exactly as it did. The view reports a SOURCE
per setting, because "this value is env" and "this value is the fleet's" look
identical until you try to change one for everybody.

Editable: the default reviewer set, the pacing floor, the weekly fair-use
threshold, and whether a repository with no explicit switch may be fixed.

A fleet save is not a per-repo save, and the UI stops pretending otherwise. It
reaches every repository that has NOT overridden the setting, so both the CLI
(--dry-run) and the dashboard ask the server what the change would do first, and
the answer is the confirmation's entire body:

  affects 7 repositories following the fleet; 19 completed round(s) would be
  reopened and reviewed again (2 with their own reviewer override are unaffected)

That number is the one worth seeing before clicking: a completed round is the
"this head was reviewed" marker, and requiring a reviewer it never had makes the
marker wrong, so the round is reopened and the metered ones spend the allowance
again.

WithFleet deliberately does not gate on UpdatedAt. A proposed record built for a
preview carries no timestamp, and short-circuiting on that made every preview
answer "nothing would change" — the one answer a preview must never give.

One watcher handles every repository, so every fix session ran with the same
model, the same effort and the same attempt budget — the ones baked into the
wrapper when autofix was installed. That is the wrong grain: a Go service worth
a slow careful model and five attempts sits next to a docs repository where a
fast one and a single attempt is the right trade.

Model, effort, an extra standing prompt, the attempt budget, the fork
permission and the skipped authors are now recorded per repository, over a
fleet default, over this host's env — the same three layers the fleet settings
use, and the view names which one answered for each setting.

The mechanism is the interesting part. The watcher's argv is fixed when it
starts, so per-repository values cannot travel in it. `crq autofix install` now
writes TWO scripts: the wrapper that starts the watcher, and a session script
the watcher runs per pull request. The session's ENVIRONMENT is built per
dispatch, so CRQ_FIX_MODEL / CRQ_FIX_EFFORT / CRQ_FIX_PROMPT reach it there.
An unset variable adds no flag at all rather than an empty one, which every
agent rejects differently and none ignores. A session script from an older
install simply ignores them, so reinstalling autofix is what turns this on.

Reading the prompt in the session rather than the wrapper is a second win:
editing it takes effect on the next session instead of the next restart.

The AGENT stays fleet-wide, and the UI says so rather than offering a control
that would do nothing. Switching between claude and codex is a different
command line, not a different flag, and a per-repository agent would mean the
watcher could not know what it was about to run until it ran it.

Values that would reach a command line are validated here instead: an unknown
effort is refused, because a session that dies on its first argument is a fix
that silently never happens. So is a standing prompt over 4000 characters —
it is appended to every session in the repository.

Emptying every field clears the record rather than leaving one that overrides
nothing, and the same now holds for the fleet record.

The Bots page listed four reviewers with no way to tell whether any of them was
running, and no way to turn one off. Both halves were wrong in a way that hid
the same fact: CRQ_COBOTS is unset on this fleet, so it defaults to all three
co-reviewers, and nothing on the page said so.

BotCard.Enabled was hardcoded true, because the list was built from the enabled
reviewers — a set that cannot contain a disabled one. It is now built from the
whole registry, so a bot crq knows how to drive gets a card whether it runs or
not. A page that lists only the enabled ones cannot answer "why is Bugbot not
reviewing this", and cannot offer the switch that would change the answer.

The switch writes the fleet's whole co-reviewer list, because that is what the
setting is — "these bots run", not a flag per bot. The primary has no switch:
it is not a co-reviewer, and turning it off is a per-repository decision.

Two bugs behind it:

The dashboard's reviewer resolution took a repository's override alone, so it
kept answering with this server's startup environment however the fleet had
been configured. It takes the state now, which is where the fleet defaults live.

The impact preview compared only the REQUIRED set, so turning a bot off
reported "nothing would change" while changing which reviewers run on seven
repositories. Running and gating are separate questions and both are changes:
turning a bot off stops its findings arriving at all, which is not the same as
it no longer holding the round open. The reopened count asks the same pair of
questions reopenForChangedReviewers does, or it under-reports the consequence
it exists to warn about — 19 rounds, in the case that found this.

Turning a bot off was a labelled button reading "Runs" or "Off", the fleet
reviewer defaults were bare checkboxes, and the repository panel already had a
proper switch. Three controls for the same decision, and the two new ones were
the worse two.

Toggle moves to ui.tsx and every on/off now uses it. It also carries its own
title rather than hardcoding one about the primary reviewer, since "why can I
not change this" is specific to whatever is locked — and gains role="switch"
with aria-checked, which the button it replaced never had.

…rner

The per-repo Reviewers card asks two questions of every bot — does it run, and
does convergence wait for it — as two labelled toggles. The Bots page asked
half of one, as a switch floating in the card header next to the "last seen"
pill, where it read as a status rather than a control.

It now has the same pair, worded and ordered the same way, and applies the same
two rules: requiring a bot turns Runs on, and turning Runs off drops the
requirement. Same questions at a different scope, so they should not look like
different questions.

The header goes back to being state alone.

The bundles are content-hashed, so a name that resolves at all resolves to the
same bytes for ever. The page that NAMES them is not: it is served from the
same fixed path every time, and a browser holding a cached copy keeps asking
for the bundle it was built against — so a restarted server serves new assets
nobody ever requests, and the dashboard silently stays a version behind while
reporting a current revision in its own header.

Hashed assets are now immutable for a year; everything else, index.html
included, is no-cache.

I put Runs and Required toggles on the Bots page. They did not belong there.
Which bots run is a property of a repository — its Reviewers card — or of the
fleet default under Settings, and offering the same switch a third time meant
three places to look for one answer, in the one place that had no business
holding it.

The page now answers what those two cannot: what IS this bot, what does it
cost, and is it actually set up. Each card carries the vendor's own pitch and
pricing in plain terms, what installing it involves, and links to sign up and
to the docs. The descriptors live in dialect with every other bot string, since
that is the one package allowed to know a bot by name; none of it affects a
decision crq makes.

Setup status is the honest part. crq cannot ask any vendor whether you have an
account — none of them offers that — so it reports only what it has SEEN the
bot do here: working, quiet, not verified, not enabled. "Enabled" and "working"
are different claims and merging them hides the case that matters. CRQ_COBOTS
defaults to all three co-reviewers, so a bot nobody signed up for reads as
configured while reviewing nothing, and crq keeps posting a trigger comment
nobody answers. That case now says so on its own card.

No referral links, and the page says so rather than staying quiet about it.

The Bots page said Bugbot was working on a fleet that has never used it. It was
reading CoBotRound.CommandedAt — the timestamp of crq POSTING "bugbot run" —
as though it were the bot doing something. Every field in that record is crq's
own bookkeeping: what it posted, and the claim it took before posting. None of
them says a bot answered, so a bot with no account behind it looked identical
to one working perfectly. crq asks, records that it asked, and nothing answers.

CoBotRound gains AnsweredAt, stamped where crq has already paid for an
observation and engine.CoReviewedHead says the bot produced head evidence — a
review, a clean summary at the SHA, a completed check run. It only moves
forward, so re-observing an old answer does not make a dormant bot look fresh.

The guide now separates the two and says which it means. The status worth
having is the one this makes possible: ASKED AND NEVER ANSWERED, which is the
actual shape of an enabled-but-unconfigured bot, and which no amount of trigger
bookkeeping could ever have shown. That card offers the setup steps and points
out that every trigger crq posts for it is a comment nobody reads.

The log is written only as rounds are observed, so it is empty right after an
upgrade — and "nothing recorded" then means "not looked yet", not "never
answered". Claiming the second would accuse a working reviewer of being
unconfigured on the strength of a field introduced minutes ago, so co-reviewers
stay "not verified" until the log has anything in it at all.

…m editable

Every setting lived in one machine's env file, so the dashboard reported "env"
beside all of them. True, and useless: it told you the value came from a file
you could not see, on a host that might not be the one you were looking at.

Three parts.

`crq fleet adopt` copies this host's settings into the shared record, so they
become the fleet's answer and every host reads the same one. It takes only what
CAN be fleet-wide. Identity — which repository holds the queue, which ref, which
issue — is reported as skipped, because a dashboard writing to that ref cannot
move it without cutting the branch it sits on. Per-host values (paths, this
machine's name, the fix agent) are skipped for the plainer reason that recording
one machine's answer would break the others. A value equal to the built-in
default is skipped too: recording one would pin today's default, invisibly, and
a later crq could never improve it.

Any setting is now fleet-settable, without each one needing plumbing of its own.
FleetDefaults carries a raw key/value map, and applying it RE-PARSES the merged
environment rather than patching fields — so a duration string becomes a
duration the same way whichever layer supplied it, and the two paths cannot
drift. LoadConfig splits into gather-then-BuildConfig to make that possible.
Keys with a typed home (reviewers, pacing, weekly limit) route there instead, so
one setting never lives in two places with one of them shadowed.

The settings page lists all 32 with their effective value, the layer that
decided it, and — where a record is overriding this host — what the host's own
file still says. Identity and per-host rows are shown but locked, with the
reason on the row: a disabled control that does not say why is worse than none.

Two labelling bugs fell out of this. "env" was reported for values nothing
configured, sending a reader to look for a line that was not there; default is
now its own answer. And a setting adopted into its typed home kept reporting
"env" afterwards, which is the exact mislabel this whole change exists to
remove. Also: resolving a reviewer list now deduplicates, since "codex" and
"chatgpt-codex-connector[bot]" name one bot and storing it twice rendered it
twice.

`crq autofix install` wrote two bash scripts — a wrapper that started the
watcher, and a session script that assembled the agent's command line. Three
things then had to agree about the configuration, and two of them were
generated text on disk that no test ever ran. A setting added to crq reached a
fleet only after every host reinstalled, and nothing said which hosts had not:
the per-repository model and effort landed a commit ago and were being ignored
on both hosts, silently, because neither had a session script that knew to read
them.

The unit now runs `crq watch -- crq fix-session`. Same binary twice: one starts
the watcher, one runs each session. The agent, its arguments and the prompt file
travel in the unit's environment, so the install writes exactly one file that is
not a unit — the prompt — and a setting reaches a host when its binary does.

Building the agent's command line moves into Go, where it is testable: the
argv builder now has the model and effort cases the shell version could not
have, including the one that matters — an unset value adds no flag at all
rather than an empty one, which every agent rejects differently and none
ignores.

It execs the agent rather than shelling to it, so the process the watcher
supervises IS the agent: killing a session kills the agent, and the exit status
is the agent's own rather than a shell's approximation of it.

…rom here

autofixCanAuthenticate asks whether the SERVICE will have a GitHub credential,
which is deliberately not the same question as whether this shell has one. On
one host it cannot answer: gh keeps its token in the macOS login keychain,
readable by a launchd agent in the GUI domain and not by an SSH session. Over
SSH there, `gh auth status` names the account and calls the token invalid —
which is also exactly what a genuinely expired token looks like.

Since the two are indistinguishable from outside that session, the escape hatch
is an explicit --skip-auth-check rather than a guess. An operator typing it has
made a claim, which is not the silent nothing the check exists to prevent, and
the flag says in one line what it is for.

Every queue and in-flight row read "coderabbit-queue#141" and nothing else, so
the dashboard was a list of ticket numbers: finding the one you cared about
meant opening them.

The title is recorded on the round. The scan that finds a pull request already
has it, so this costs no request — and a round already at the current head is
never a candidate, so it would never be written again and would read as a bare
number for ever. One converging write fixes that: once every round has its
title nothing changes and the CAS reports no change. Stale after a rename,
which is a fair price for a list that says what it is listing.

With titles there is something to search, so there is now a search box and
filter chips (all / in flight / queued / held / fixing / needs attention).
Filtering is client-side because the whole snapshot is already in the page: it
costs nothing and cannot go stale against the tables it narrows. A narrowed
count reads "3 of 9" rather than "3", since a filtered table that says 3 reads
as a fleet that suddenly has less work in it.

Two more gaps from the mockups, both about a page that had gone read-only:

A pull request opened by link could not be held or cancelled. Those actions
existed only as hover buttons on an Overview row, which is not where you are
when you have just read its findings. Both are on the PR page now, with the
consequence stated — cancelling a fired round says that it releases the slot.

The fix-session card said "attempt 2", which tells you nothing about whether
that is nearly the last one. It now carries the repository's attempt budget,
how many findings the session set out to fix, and where its log is going.

Two gaps the mockups had and the implementation did not.

Every needs-attention item described a problem and left you to find the page
that fixes it. They now carry a link: a broken host opens the host list, a
stranded reservation opens the pull request, an expired leader opens setup, the
fair-use warning opens fleet settings. An item that only describes a problem is
a notification; one that points at the thing that fixes it is a control.

A hold could only be placed from an Overview row — from the one page that shows
every repository at once. So the answer to "stop reviewing this while I rework
it" was to go and find it in a list of everything. Holds for a repository now
live on that repository's page, with the reason each carries, an Unhold beside
each, and a form to place one. It also says how many are held elsewhere, since
a repository page that shows two holds should not read as a fleet with two.

Every question about a fleet turns into a per-host question, and crq could only
answer for whichever machine you happened to be asking from. "Is claude
installed" has a different answer on each host — and on any one host, a
different answer again between your shell and the service, which is the whole
failure: a tool installed for you and invisible to the daemon looks fine
everywhere except in the fix session that needs it.

Each host now reports itself into shared state: its crq version, what that
binary understands, the services running there, and the tools it can reach.
Reported, never inferred — nothing may write a record for another machine,
because a host that has stopped reporting is exactly the one whose last claim
about itself should stop being trusted. A stale record is kept and marked
rather than dropped: "atlas last said it had claude, two days ago" beats an
empty row, and the silence is itself the finding.

The PATH probed is the reporting process's own, so a daemon reports the PATH a
fix session inherits. That is the number that decides whether the agent starts.

Setup gains the tool × host matrix and a ready / needs-attention / optional
summary, so the page opens with a verdict rather than a list to count. The
solver card gains the same inventory as capability beside its policy: a
repository could be set to an agent no host can run, and nothing said so.

Reporting writes nothing when nothing changed and the record is still fresh,
so a daemon polling every minute does not bump the state revision every minute
and make the activity feed report a fleet that is constantly doing something.

Three smaller mockup gaps.

Each co-reviewer's trigger mode, self-heal grace and command are settings like
any other, but were reachable only by editing an env file. They are generated
from the registry rather than listed, so adding a co-reviewer adds its settings
too — a hand-written catalogue silently stops covering the fleet it describes.
A trigger that is not one of the three modes is refused: it would be accepted,
written for every host, and then ignored.

A fleet default now names the repositories it does NOT reach, and links to
them. The count alone was a number you could not act on, and "affects 7
repositories" says nothing about which two are exempt or why.

The solver card shows, per host, whether the configured agent is actually
there — capability beside policy. A repository could be set to an agent no
machine can run and nothing said so. A host that has never reported reads as
unknown rather than missing, because blaming a machine for crq's own blind spot
is worse than admitting the blind spot.

Also fixes a bug the host table found in itself: two crq services on one
machine each reported only their own role, so the autofix watcher and the
review daemon took turns overwriting each other and the table showed whichever
wrote last as the only thing running there. Roles merge; they are dropped only
when the whole record ages out.

Two mockup gaps at opposite ends of the product.

Adding a repository is the one click here that can spend real money: one with a
dozen open pull requests becomes a dozen metered reviews on the next pass, and
the button said "Add". It now prices the backlog first — open pull requests,
how many would actually be enqueued once the skip rules apply, what the gap is
for, and the range that would cost. Enrolling imageoptim, for instance, reads
"would enqueue 8 of 8 open pull request(s) on the next pass — roughly
$9.50–$28.80". Nothing is written until that has been shown.

It prices the first 25 and says so rather than making a dialog nobody waits
for, and a price it could not work out leaves the dialog up saying so instead
of quietly becoming a free-looking Add.

The other end: a fleet with nothing enrolled landed on an empty Overview, which
says the queue is idle — indistinguishable from a queue that works and has
nothing to do. It now gets a page that says what crq is for in three sentences
(the metered lane, the free one, and fixing), and a checklist that answers
itself from live state: whether the queue has a home, whether a daemon holds
the lease, how many reviewers crq has actually SEEN work here as against how
many are merely enabled, whether a fix agent exists.

Derived, not a mode: it renders when nothing is enrolled and nothing has ever
been queued, and stops the moment either becomes false. There is no first-run
flag to get stuck on.

A converged pull request said "converged" in a pill and nothing else, so the
one question it raises — is there anything for me to do — was answered by
absence. It now leads with the verdict, which reviewers actually answered, and
what happens next: nothing, merge when ready, and pushing another commit
enqueues a fresh round. A converged round records that THIS head was reviewed,
not that the pull request is finished, and reading it as the second is how a
head goes out unreviewed.

The bot guide's cost line now carries the date its prices were checked. An
undated price is a price that has quietly stopped being true, and CodeRabbit's
are already roughly double the figures widely cited a year ago.

And a bot crq has not seen working gets a suggestion when there is evidence for
one — right now: "the codex CLI is on cachyos, so the account behind it is
probably already yours". That is the honest signal available, and it covers
both cases worth a nudge: a bot switched off that you evidently have an account
for, and one switched on that has never answered, where a CLI on a host says
the account is fine and the setup is not. No evidence, no badge — a suggestion
with no stated criterion is an advertisement.

Unenrolling asked for a reason and told you nothing about consequences. It now
states the contract: no new rounds are enqueued, the ones already in flight
finish (named, with a count, and where to cancel them sooner), and every
setting is kept so turning it back on restores them rather than starting over.

Setup gains the two summaries the mockup carries. Review bots, with what crq
has actually seen each one do — the distinction that matters, since enabled and
working are different claims. And repositories, which flags the ones still
enrolled by this host's env file, because those are exactly the ones the other
hosts decide for themselves, and points at the command that fixes it.

The mockups' signature affordance: a gear on any queue or in-flight row opens
that repository's reviewers where you noticed you wanted to change them, rather
than sending you to find it in a list of every repository.

Deliberately only the reviewers, not a second settings page. A slide-over that
grows into one is two places to look for one answer, which is the mistake the
Bots page already made once — so it carries the two toggles and a link to
everything else.

It says what saving would DO before you save, in the terms that matter here:
which bots would be newly enabled, and how many rounds already in flight would
be reconsidered at their current heads. That is a consequence, not a preference.

Missing tools on the Setup page now carry the command that installs them, and
the reason installing is not enough: the service gets its own PATH, so a tool
that works in your shell is still invisible to the thing that needs it.

Every other crq service reports its role, so the host table named the review
daemon and the fix watcher and stayed silent about the one machine you are
certainly talking to — the one serving the page you are reading it on.